Begin by answering some basic questions, including;
What is a scanner?
What does a scanner do?
On what platforms are scanners available?
What system requirements are involved to run a scanner?
Is it difficult to create a scanner?
What will a scanner tell me?
What won't a scanner tell me?
Are scanners legal?
Why are scanners important to Internet security?
After answering these questions, I will examine the historical background of scanners.
From there, I cover the scanner from a more practical viewpoint. I will
differentiate between true
scanners are other diagnostic network tools. I will examine different
types of scanners, especially
very popular ones (such as SATAN and Strobe). At that point, you will
gain understanding of what
constitutes a scan and what ingredients are necessary to create a scanner.
Finally, you will conduct a scan and analyze what information has been
gained from it. In this way,
you will derive an inside look at scanner functionality. By the end
of this chapter, you will know what
a scanner is, how to deploy one, and how to interpret the results from
a scan. In short, I will prepare
you for actual, network combat using scanners.
Scanners
In Internet security, no hacking tool is more celebrated than the scanner.
It is said that a good TCP
port scanner is worth a thousand user passwords. Before I treat the
subject of scanners in depth, I
want to familiarize you with scanners.
What Is a Scanner?
A scanner is a program that automatically detects security weaknesses
in a remote or local host. By
deploying a scanner, a user in Los Angeles can uncover security weaknesses
on a server in Japan
without ever leaving his or her living room.
How Do Scanners Work?
True scanners are TCP port scanners, which are programs that attack
TCP/IP ports and services
(Telnet or FTP, for example) and record the response from the target.
In this way, they glean
valuable information about the target host (for instance, can an anonymous
user log in?).
Other so-called scanners are merely UNIX network utilities. These are
commonly used to discern
whether certain services are working correctly on a remote machine.
These are not true scanners,
but might also be used to collect information about a target host.
(Good examples of such utilities are
the rusers and host commands, common to UNIX platforms.) Such utilities
are discussed later in this
chapter.
Cross Reference: rusers gathers information
about users currently logged to the
targeted host and in this way, closely resembles
the UNIX utility finger. host is also
a UNIX utility, designed to interactively
query name servers for all information held on
the targeted host.
On What Platforms Are Scanners Available?
Although they are commonly written for execution on UNIX workstations,
scanners are now written
for use on almost any operating system. Non-UNIX scanning tools are
becoming more popular now
that the rest of the world has turned to the Internet. There is a special
push into the Microsoft
Windows NT market, because NT is now becoming more popular as an Internet
server platform.
What System Requirements Are Necessary to Run a Scanner?
System requirements depend on the scanner, your operating system, and
your connection to the
Internet. Certain scanners are written only for UNIX, making UNIX a
system requirement. There
are, however, more general requirements of which to be aware:
You might encounter problems if you are running
an older Macintosh or IBM compatible with
a slow Internet connection (as would be the
case if you used Windows 3.11 running
TCPMAN as a TCP/IP stack, via a 14.4 modem).
These configurations might cause stack
overflows or general protection faults, or
they might simply cause your machine to hang.
Generally, the faster your connection, the
better off you are. (And naturally, a true 32-bit
system contributes greatly to performance.)
RAM is another issue, mainly relevant to window-system-based
scanners. Command-line
scanning utilities typically require little
memory. Windowed scanners can require a lot. (For a
comparison, I suggest running ISS. First,
try the older, command-line version. Then run the
new Xiss, which operates through MIT's X Window
System, OpenWindows, or any
compatible UNIX-based windowing system. The
difference is very noticeable.)
Bottom line, you must have a compatible operating system, a modem (or
other connection to the
Net), and some measure of patience. Not all scanners work identically
on different platforms. On
some, this or that option might be disabled; on others, sometimes very
critical portions of the
application might not work.
Is It Difficult to Create a Scanner?
No. However, you will require strong knowledge of TCP/IP routines and
probably C, Perl, and/or
one or more shell languages. Developing a scanner is an ambitious project
that would likely bring the
programmer much satisfaction. Even so, there are many scanners available
(both free and
commercial), making scanners a poor choice as a for-profit project.
You will also require some background in socket programming, a method
used in the development
of client/server applications.
Cross Reference: There are many resources online
to help you get started; I list two
here. The first is a bare-bones introduction
to socket programming generated by Reg
Quinton at The University of Western Ontario.
It can be found at
http://tecstar.cv.com/~dan/tec/primer/socket_programming.html.
Another excellent source for information about
socket programming is provided by
Quarterdeck Office Systems as an online programming
resource. It addresses all
supported BSD 4.3 socket routines and is very
comprehensive. It is located at
http://149.17.36.24/prog/sockets.html.
What Will a Scanner Tell Me?
A scanner might reveal certain inherent weaknesses within the target
host. These might be key
factors in implementing an actual compromise of the target's security.
In order to reap this benefit,
however, you must know how to recognize the hole. Most scanners do
not come with extensive
manuals or instructions. Interpretation of data is very important.
What Won't a Scanner Tell Me?
A scanner won't tell you the following:
A step-by-step method of breaking in
The degree to which your scanning activity has been logged
Are Scanners Legal?
Yes. Scanners are most often designed, written, and distributed by security
personnel and
developers. These tools are usually given away, via public domain,
so that system administrators can
check their own systems for weaknesses. However, although scanners
are not illegal to possess or
use, employing one if you are not a system administrator would meet
with brutal opposition from the
target host's administrator. Moreover, certain scanners are so intrusive
in their probing of remote
services that the unauthorized use of them may violate federal or state
statutes regarding unauthorized
entry of computer networks. This is a matter of some dispute and one
not yet settled in law.
Therefore, be forewarned.
WARNING: Do not take scanning activity lightly.
If you intend to scan wide ranges of
domains, check the laws in your state. Certain
states have extremely particular
legislation. The wording of such statutes
is (more often than not) liberally construed in
favor of the prosecution. For example, the
state of Washington has provisions for
computer trespass. (Wash. Rev. Code Sec. 9A.52
110-120.) If you deploy a
scanner that attempts to steal the passwd
file (a password file on the UNIX platform
located in the directory /ETC), you might
actually have committed an offense. I will
discuss legal issues of hacking and cracking
in
Why Are Scanners Important to Internet Security?
Scanners are important to Internet security because they reveal weaknesses
in the network. Whether
this information is used by hackers or crackers is immaterial. If used
by system administrators,
scanners help strengthen security in the immediate sense. If employed
by crackers, scanners also
help strengthen security. This is because once a hole has been exploited,
that exploitation will
ultimately be discovered. Some system administrators argue that scanners
work against Internet
security when in the hands of crackers. This is not true. If a system
administrator fails to adequately
secure his or her network (by running a scanner against it), his or
her negligence will come to light in
the form of a network security breach.
Historical Background
Scanners are the most common utilities employed by today's cracker.
There is no mystery as to why:
These programs, which automatically detect weaknesses within a server's
security structure, are fast,
versatile, and accurate. More importantly, they are freely available
on the Internet. For these
reasons, many sources insist that the scanner is the most dangerous
tool in the cracking suite.
To understand what scanners do and how they are employed, you must look
to the dawn of
computer hacking. Transport yourself to the 1980s, before the personal
computer became a
household item. The average machine had a 10MB hard disk drive and
a whopping 640K memory.
In fact, our more mature readers will remember a time when hard disk
drives did not exist. In those
early days, work was done by rotating through a series of 5" floppy
diskettes; one for the operating
system, one for the current program, and one to save your work.
Those early days are rather amusing in retrospect. Communications were
conducted, if at all, with
modems ranging in speed from 300 to 1200bps. Incredibly, we got along
rather well with these
meager tools.
The majority of users had never heard of the Internet. It existed, true,
but was populated primarily by
military, research, and academic personnel. Its interface--if we could
call it that--was entirely
command-line based. But these were not the only limitations preventing
America from flocking to the
Net. Machines that could act as servers were incredibly expensive.
Consider that Sun Microsystems
workstations were selling for five and six figures. Today, those same
workstations--which are
scarcely more powerful than a 25MHz 386--command less than $800 on
Usenet.
We're talking frontier material here. Civilians with Internet access
were generally students with
UUCP accounts. Dial-up was bare-bones, completely unlike today's more
robust SLIP, PPP, and
ISDN access. In essence, the Internet was in its infancy, its existence
largely dependent on those
early software authors concerned with developing the system.
Security at that point was so lax that some readers will wonder why
the Internet was not completely
overtaken by crackers. The answer is simple. Today, there are massive
online databases and mailing
lists that broadcast weaknesses of a dozen different operating systems.
Table 9.1 lists a few
examples.
Table 9.1. Online mailing lists of security holes.
Resource
Location
Firewalls mailing list
Firewalls@GreatCircle.COM
Sneakers mailing list
Sneakers@CS.Yale.EDU
The WWW security list
WWW-security@ns2.rutgers.edu
The NT security list
Ntsecurity@ISS
Bugtraq
BUGTRAQ@NETSPACE.ORG
Dozens of such mailing lists now exist on the Internet (for a comprehensive
list, see Appendix A,
"How to Get More Information"). These lists operate almost completely
free of human interaction or
maintenance. List members forward their reports via e-mail, and this
e-mail is distributed to the entire
list, which can sometimes be many thousands of people worldwide. In
addition, such lists are usually
archived at one or more sites, which feature advanced search capabilities.
These search capabilities
allow any user, list member, or otherwise to search for inherent vulnerabilities
in every operating
system known to humankind.
Joining a list: Joining such a list is generally
a simple process. Most lists require that
you send an e-mail message to a special address.
This address accepts commands
from your first line of the e-mail message.
The structure of this command may vary. In
some cases, that command is as simple as subscribe.
In other cases, you may be
required to issue arguments to the command.
One such argument is the name of the list.
For example, the Firewalls mailing list at
GreatCircle.com requires that you send
subscribe firewalls as the first line of your
e-mail.
Please note that this must be the first line
of the e-mail message, and not the subject
line. This message is then sent to majordomo@greatcircle.com.
The address
majordomo is a very common one for processing
mailing list subscription requests. Of
course, each list is different. To quickly
determine the requirements for each security
list, I suggest you use Eugene Spafford's
Web page as a springboard. Mr. Spafford
lists links on his page to most of the well-known
security mailing lists.
Cross Reference: Spafford's page is at
http://www.cs.purdue.edu/homes/spaf/hotlists/csec-top.html.
From Spafford's
page, you can get to instructions on how to
subscribe to any of the linked lists.
In the beginning, however, there were no such databases. The databases
did not exist largely
because the knowledge did not exist. The process by which holes get
discovered inherently involves
the exploitation of such weaknesses. More simply put, crackers crack
a machine here and a machine
there. By and by, the weaknesses that were exploited in such attacks
were documented (and in
certain instances, eradicated by later, superior code). This process,
as you might expect, took many
years. The delay was based in part on lack of knowledge and in part
on the unwillingness of many
system administrators to admit their sites had been penetrated. (After
all, no one wants to publicize
that he implements poor security procedures.)
So the stage is set. Picture a small, middle-class community with stately
homes and nicely trimmed
lawns. It is near midnight. The streets are empty; most of the windows
in the neighborhood are dark,
their shades drawn tight. One window is brightly lit, though, and behind
it is a young man of 15
years; before him is a computer (for the sake of atmosphere, let's
label it an old portable CoreData).
The boy is dialing a list of telephone numbers given to him by a friend.
These are known UNIX
boxes sprinkled throughout a technology park a few miles away. Most
of them accept a connection.
The common response is to issue a login prompt. Each time the boy connects
to such a machine, he
tries a series of login names and passwords. He goes through a hundred
or more before finally, he
obtains a login shell. What happens then is up to him.
It is hard to believe that early cracking techniques involved such laborious
tasks. Depending on the
operating system and the remote access software, one might have to
type dozens of commands to
penetrate a target. But, as much as crackers are industrious, they
are also lazy. So, early on, the war
dialer was developed.
A war dialer consists of software that dials a user-specified range
of telephone numbers searching
for connectables (machines that will allow a remote user to log in).
Using these tools, a cracker can
scan an entire business exchange in several hours, identifying all
hosts within that range. In this way,
the task of locating targets was automated.
Better yet, war dialers record the response they receive from each connect.
This data is then
exported to a human-readable file. Thus, in neatly written tables,
one can tell not only which numbers
connected, but also what type of connection was initiated (such as
modem, 2400 baud or fax
machine).
NOTE: The term war dialer reportedly originated
from the film WarGames. The film's plot centered around
a young man who cracked his way into American military
networks. Some people believe that the film
was inspired by the antics of the
now-famous cracker, Kevin Mitnik. Mitnik was
a young teen when he cracked a key
military network.
Cross Reference: If you want to check out a
war dialer in action, I suggest getting
Toneloc. It is freely available on the Internet
and is probably the best war dialer ever
made. It was written to run in DOS, but it
also runs in Windows 95 via command
prompt (though perhaps not as smoothly as
it should). It is available at
ftp://ftp.fc.net/pub/defcon/TONELOC/tl110.zip.
In essence, scanners operate much like war dialers with two exceptions:
Scanners are used only on the Internet or other TCP/IP networks.
Scanners are more intelligent than war dialers.
Early scanners were probably very simplistic. I say probably because
such programs were not
released to the Internet community the way scanning tools are today
(I therefore have no way of
knowing what they looked like). Thus, when I write of early scanners,
I mean basic programs written
by system administrators for the purposes of checking their own networks.
These were most likely
UNIX shell scripts that attempted to connect on various ports, capturing
whatever information was
directed to the console or STDOUT. STDOUT refers to the output that
one sees on the console or at a
command prompt. In other words, it is the output of a given command.
The STD refers to standard,
and the OUT refers to output. STDOUT, therefore, is the standard output
of any given command. The
STDOUT result of a directory listing, for example, is a list of filenames
and their sizes.
The Attributes of a Scanner
The primary attributes of a scanner are
The capability to find a machine or network
The capability, once having found a machine,
to find out what services are being run on the
host
The capability to test those services for known holes
This process is not incredibly complex. At its most basic, it involves
capturing the messages
generated when one tries to connect to a particular service. To illustrate
the process step by step,
let's address these attributes one at a time.
Locating a Potential Target
The Internet is vast. There are literally millions of potential targets
in the void. The problem facing
modern crackers is how to find those targets quickly and effectively.
Scanners are well suited for this
purpose. To demonstrate how a scanner can find a potential target,
determine what services it is
running, and probe for weaknesses, let's pick on Silicon Graphics (SGI)
for the remainder of this
section. Here, you will see how scanners are regularly employed to
automate human cracking tasks.
A Hole Is Discovered
In late 1995, Silicon Graphics (SGI) shipped a large number of WebForce
models. These were
extremely powerful machines, containing special software to generate
media-rich WWW pages.
They ran IRIX, a proprietary form of UNIX, specifically designed for
use with SGI graphics
workstations.
Certain versions of IRIX retained a default login for the line printer.
That is, if a user initiated a Telnet
session to one of these SGI boxes and logged in as lp, no password
would be required.
Typically, the cracker would be dropped to a shell prompt from which
he or she could execute a
limited number of commands. Most of these were standard shell commands,
available to any user on
the system. These did not require special privileges and performed
only basic functions, such as
listing directories, displaying the contents of files, and so forth.
Using these commands, crackers
could print the contents of the passwd file to the screen. Once they
had obtained this display, they
would highlight the screen, clip the contents, and paste them into
a text editor on their local machine.
They would save this information to a local file and subsequently crack
the encrypted passwords
from the SGI system.
TIP: A number of automated password-cracking
utilities exist. Most often, these are
designed to crack DES-encrypted passwords,
common to UNIX systems. I will cover
these utilities in Chapter 10, "Password Crackers."
News of this vulnerability spread quickly. Within days, the word was
out: SGI WebForce machines
could be attacked (and their security compromised) with little effort.
For crackers, the next step was
to find these machines.
Looking for WebForce Models
To exploit this hole, crackers needed to find WebForce models. One way
to do so was manually.
For a time, search engines such as altavista.digital.com could be used
to locate such
machines en masse. This is because many of the WebForce models were
administrated by those
with strong knowledge of graphic arts and weak knowledge of security.
These administrators often
failed to institute even the most basic security measures. As such,
many of these machines retained
world-readable FTP directories. These directories were therefore visible
to search engines across
the Internet.
The FTP directories of these SGI models contained standard, factory-default
/etc/passwd files.
Contained within these were the login names of system users. The majority
of these login names
were common to almost any distribution of UNIX. However, these passwd
files also included
unique login names. Specifically, they contained login names for several
utilities and demo packages
that shipped with the software. One of these was a login called EZSetup.
Thus, a cracker needed
only to issue the following search string into any well known search
engine:
EzSetup + root: lp:
This would return a list of WebForce models. The cracker would then
take that list and attempt to
crack each machine. It was a quick and dirty way to collect a handful
of potential targets. However,
that trend didn't last long (about a month or so). Advisories were
posted to the Net, explaining that
world-readable directories were responsible for the compromise of SGI
security. So crackers
turned elsewhere.
Some used the InterNIC database to find such machines (the WHOIS service).
The WHOIS
service, housed at internic.net, is a database of all registered machines
currently on the Internet.
One can query this database (to find out the network numbers or the
owner's address of a given
machine) by issuing a WHOIS instruction at a UNIX command prompt. The
structure of such a
command is whois mci.net. For those who do not use UNIX, one can either
Telnet directly to
InterNIC (internic.net) or use one of the utilities described later
in this chapter.
Many hosts included words within their registered names that suggested
at least a fleeting probability
that they owned an SGI, such as
Graphics
Art
Indy
Indigo
The terms Indy and Indigo commonly appear on either the Web site or
the directory structure of
an SGI workstation. That is because the product line is based on the
Indigo model, which is often
referred to as the Indy product line.
Some InterNIC entries also include the operating system type being run
on the host. Thus, a search
for the string IRIX could reveal a few machines. However, these methods
were unreliable. For
example, many versions of IRIX did not suffer from the lp bug (neither
did every WebForce model).
So, instead, many crackers employed scanners.
Using Scanners to Uncover WebForce Models
Finding WebForce models using a scanner was an easy task. A range of
addresses (such as
199.171.190.0 to 199.171.200.0) would be picked out, perhaps randomly,
perhaps not. The
cracker would specify certain options. For example, the scan didn't
need to have great depth (an
issue we will be discussing momentarily). All it needed to do was check
each address for a Telnet
connection. For each successful connection, the scanner would capture
the resulting text. Thus, a
typical entry might look something like this:
Trying 199.200.0.0
Connected to 199.200.0.0
Escape Character is "]"
IRIX 4.1
Welcome to Graphics Town!
Login:
The resulting information would be written to a plain text file for later viewing.
Talented crackers would write an ancillary program to automate the entire
process. Here are the
minimum functions that such a program would require:
Start the scan, requesting the option to test Telnet connections for the lp login.
Wait until a signal indicating that the scan is completed is received.
Access the result file, exporting only those results that show successful penetration.
Format these results into flat-file, database format for easy management.
The scan would run for several hours, after which the cracker would
retrieve a list of compromised
Indy machines. Later, perhaps at night (relative to the geographical
location of the target host), the
cracker would log in and being the process of grabbing the password
files.
TIP: If you know of an SGI machine and you
want to view the IP address of the last
person who exploited this vulnerability, finger
lp@the.sgi.box. This author traced
down a person at Texas A&M University
who was compromising machines from Los
Angeles to New York using this technique.
This young man's originating address
appeared on 22 machines. (Some of these were
of well- known institutions. While we
cannot identify them here, one was a graphic
design school in New York City. Another
was a prominent gay rights organization in
Los Angeles. To this day, these machines
may well be vulnerable to such an attack.
Alas, many SGI users are gifted graphic
artists but have little background in security.
A renowned university in Hawaii missed
this hole and had an entire internal network
torn to pieces by a cracker. He changed
the root passwords and destroyed valuable
data.)
NOTE: If you currently have a WebForce model,
you can test whether it is vulnerable
to this simple attack. First, Telnet to the
machine. When confronted with a login
prompt, enter the string lp and press Enter.
If you are immediately logged into a shell,
your machine is vulnerable. If so, this can
be quickly remedied by opening the file
/etc/passwd and inserting an asterisk between
the first and second fields for the user
lp. Thus, the leading portion of the line
would look like this:
lp:*:4:7:lp:/var/spool/lpd:
instead of like this:
lp::4:7:lp:/var/spool/lpd:
The idea is to create a locked login. If you
fail to do so, the problem will remain
because the system is configured to accept
a line printer login without requesting a
password.
Of course, this is a very primitive example, but it illustrates how
potential targets are sometimes
found with scanners. Now I want to get more specific. Momentarily,
you will examine various
scanners currently available on the Internet. Before that, however,
you need to distinguish between
actual scanners and network utilities that are not scanners.
Network Utilities
Sometimes people erroneously refer to network utilities as scanners.
It is an easy mistake to make.
In fact, there are many network utilities that perform one or more
functions that are also performed
during a bona fide scan. So, the distinction is significant only for
purposes of definition.
Because we are focusing on scanners, I would like to take a moment to
illustrate the distinction. This
will serve two purposes: First, it will more clearly define scanners.
Second, it will familiarize you with
the rich mixture of network resources available on the Internet.
The network utilities discussed next run on a variety of platforms.
Most of them are ported from
UNIX environments. Each utility is valuable to hackers and crackers.
Surprisingly, garden-variety
network utilities can tell the user quite a bit, and these utilities
tend to arouse less suspicion. In fact,
many of them are totally invisible to the target host. This is in sharp
contrast to most scanners, which
leave a large footprint, or evidence of their existence, behind. In
this respect, most of these utilities
are suitable for investigating a single target host. (In other words,
the majority of these utilities are not
automated and require varying levels of human interaction in their
operation.)
host
host is a UNIX-specific utility that performs essentially the same operation
as a standard nslookup
inquiry. The only real difference is that host is more comprehensive.
Note, too, that various
non-UNIX utilities discussed in the following pages also perform similar
or equivalent tasks.
host ranks as one of the ten most dangerous and threatening commands
in the gamut. To
demonstrate why, I pulled a host query on Boston University (BU.EDU).
The command line given
was
host -l -v -t any bu.edu
The output you are about to read is astonishing. A copious amount of
information is available,
including data on operating systems, machines, and the network in general.
(Also, if you are deep
into security, some preliminary assumptions might be made about trust
relationships.) Examine a few
lines. First, let's look at the basic information:
Found 1 addresses for BU.EDU
Found 1 addresses for RS0.INTERNIC.NET
Found 1 addresses for SOFTWARE.BU.EDU
Found 5 addresses for RS.INTERNIC.NET
Found 1 addresses for NSEGC.BU.EDU
Trying 128.197.27.7
bu.edu 86400 IN SOA
BU.EDU HOSTMASTER.BU.EDU(
961112121 ;serial (version)
900 ;refresh period
900 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
bu.edu 86400 IN NS
SOFTWARE.BU.EDU
bu.edu 86400 IN NS
RS.INTERNIC.NET
bu.edu 86400 IN NS
NSEGC.BU.EDU
bu.edu 86400 IN A
128.197.27.7
This in itself is not damaging. It identifies a series of machines and
their name servers. Most of this
information could be collected with a standard WHOIS lookup. But what
about the following lines:
bu.edu 86400 IN HINFO
SUN-SPARCSTATION-10/41 UNIX
PPP-77-25.bu.edu 86400 IN A
128.197.7.237
PPP-77-25.bu.edu 86400 IN HINFO
PPP-HOST PPP-SW
PPP-77-26.bu.edu 86400 IN A
128.197.7.238
PPP-77-26.bu.edu 86400 IN HINFO
PPP-HOST PPP-SW
ODIE.bu.edu 86400 IN A
128.197.10.52
ODIE.bu.edu 86400 IN MX
10 CS.BU.EDU
ODIE.bu.edu 86400 IN HINFO
DEC-ALPHA-3000/300LX OSF1
Here, we are immediately aware that a DEC Alpha running OSF/1 is available
(ODIE.bu.edu).
And then:
STRAUSS.bu.edu 86400 IN HINFO
PC-PENTIUM DOS/WINDOWS
BURULLUS.bu.edu 86400 IN HINFO
SUN-3/50 UNIX (Ouch)
GEORGETOWN.bu.edu 86400 IN HINFO
MACINTOSH MAC-OS
CHEEZWIZ.bu.edu 86400 IN HINFO
SGI-INDIGO-2 UNIX
POLLUX.bu.edu 86400 IN HINFO
SUN-4/20-SPARCSTATION-SLC UNIX
SFA109-PC201.bu.edu 86400 IN HINFO
PC MS-DOS/WINDOWS
UH-PC002-CT.bu.edu 86400 IN HINFO
PC-CLONE MS-DOS
SOFTWARE.bu.edu 86400 IN HINFO
SUN-SPARCSTATION-10/30 UNIX
CABMAC.bu.edu 86400 IN HINFO
MACINTOSH MAC-OS
VIDUAL.bu.edu 86400 IN HINFO
SGI-INDY IRIX
KIOSK-GB.bu.edu 86400 IN HINFO
GATORBOX GATORWARE
CLARINET.bu.edu 86400 IN HINFO
VISUAL-X-19-TURBO X-SERVER
DUNCAN.bu.edu 86400 IN HINFO
DEC-ALPHA-3000/400 OSF1
MILHOUSE.bu.edu 86400 IN HINFO
VAXSTATION-II/GPX UNIX
PSY81-PC150.bu.edu 86400 IN HINFO
PC WINDOWS-95
BUPHYC.bu.edu 86400 IN HINFO
VAX-4000/300 OpenVMS
I have omitted the remaining entries for sake of brevity. The inquiry
produced a plain text file of
some 70KB (over 1500 lines in all).
The point here is this: Anyone, with a single command-line, can gather
critical information on all
machines within a domain. When crackers looks at the preceding information,
they are really seeing
this:
ODIE.bu.edu is a possible target for the mount
-d -s bug, where if two successive mount
-d -s commands are sent within seconds of
one another (and before another host has issued
such a request), the request will be honored.
CHEEZEWIZ.bu.edu is a potential target for
either the lp login bug or the Telnet bug. Or
maybe, if we're on site, we can exploit the
floppy mounter bug in /usr/etc/msdos.
POLLUX.bu.edu is an old machine. Perhaps Sun
Patch-ID# 100376-01 hasn't been applied.
Maybe they put in a fresh install of SunOS
4.1.x and the SPARC integer division is shredded.
I see that PSY81-PC150.bu.edu is running Windows
95. I wonder whether the SMB
protocol is running and if so, are any local
directories shared out? Using Samba on a Linux
box, perhaps I can attach one of the shared
out directories from anywhere on the Internet
simply by specifying myself as a guest.
As you can easily see, even minor information about the operating system
can lead to problems. In
reality, the staff at BU.EDU has likely plugged all the holes mentioned
here. But that doesn't mean that
every host has. Most haven't.
A host lookup takes less than three seconds, even when the network is
under heavy system load. It
is quick, legal, and extremely revealing.
CAUTION: There are various ways to protect
against this. One way is to run a
firewall. Another is to restrict queries of
name servers to a particular set of addresses.
Another is to completely disallow outside
access to your name servers.
Traceroute
Traceroute's name is quite descriptive. In short, it traces the route
between two machines. As
explained in the man (manual) page:
Tracking the route one's packets follow (or
finding the miscreant gate way that's discarding
your packets) can be difficult. Traceroute
utilizes the IP protocol `time to live' field and
attempts to elicit an ICMP TIME_EXCEEDED response
from each gateway along the path
to some host.
NOTE: Man pages are manual pages on the UNIX
platform. These are the equivalent
of help files. They can be called from a command
prompt or from a windowed system.
On a full install of UNIX, these man pages
cover help on all commands one can issue
from a prompt. They also cover most programming
calls in C and C++.
This utility can be used to identify the location of a machine. Suppose,
for example, that you are
trying to track down an individual who posted from a box connected
to his or her ISP via PPP.
Suppose that the posting revealed nothing more than an IP address that,
when run through a
WHOIS search, produces nothing (that is, the address is not the address
of a registered domain).
You can find that machine by issuing Traceroute requests. The second
to last entry is generally the
network from which the activity originated. For example, examine this
Traceroute trace going from a
machine in France (freenix.fr) to mine:
1 193.49.144.224 (193.49.144.224) 3 ms 2 ms
2 ms
2 gw-ft.net.univ-angers.fr (193.49.161.1) 3 ms
3 ms 3 ms
3 angers.or-pl.ft.net (193.55.153.41) 5 ms
5 ms 5 ms
4 nantes1.or-pl.ft.net (193.55.153.9) 13 ms
10 ms 10 ms
5 stamand1.renater.ft.net (192.93.43.129) 25 ms
44 ms 67 ms
6 rbs1.renater.ft.net (192.93.43.186) 45 ms
30 ms 24 ms
7 raspail-ip2.eurogate.net (194.206.207.18) 51 ms
50 ms 58
8 raspail-ip.eurogate.net (194.206.207.58) 288 ms311 ms
287 ms
9 * Reston.eurogate.net (194.206.207.5) 479 ms
469 ms
10 gsl-sl-dc-fddi.gsl.net (204.59.144.199) 486 ms 490 ms
489 ms
11 sl-dc-8-F/T.sprintlink.net (198.67.0.8) 475 ms *
479 ms
12 sl-mae-e-H2/0-T3.sprintlink.net (144.228.10.42)498 ms
478 ms
13 mae-east.agis.net (192.41.177.145) 391 ms 456
ms 444 ms
14 h0-0.losangeles1.agis.net (204.130.243.45)714 ms 556 ms714
ms
15 pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505
ms
16 lsan03-agis1.pbi.net (206.13.29.2) 536 ms 560
ms *
17 * * *
18 pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms
561 ms
19 pm1-24.pacificnet.net (207.171.17.25) 687 ms 677
ms 714 ms
From this, it is clear that I am located in Los Angeles, California:
pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms
and occupy a place at pacificnet.net:
pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms
Traceroute can be used to determine the relative network location of a machine in the void.
Note that you needn't have UNIX (or a UNIX variant) to run Traceroute
queries. There are
Traceroute gateways all over the Internet. And, although these typically
trace the route only between
the Traceroute gateway and your target, they can at least be used to
pin down the local host of an IP
address.
Cross Reference: Try the Traceroute gateway
at
http://www.beach.net/traceroute.html.
rusers and finger
rusers and finger can be used together to glean information on individual
users on a network.
For example, a rusers query on the domain wizard.com returns this:
gajake snark.wizard.com:ttyp1
Nov 13 15:42 7:30 (remote)
root snark.wizard.com:ttyp2
Nov 13 14:57 7:21 (remote)
robo snark.wizard.com:ttyp3
Nov 15 01:04 01 (remote)
angel111 snark.wizard.com:ttyp4 Nov14
23:09 (remote)
pippen snark.wizard.com:ttyp6 Nov
14 15:05 (remote)
root snark.wizard.com:ttyp5
Nov 13 16:03 7:52 (remote)
gajake snark.wizard.com:ttyp7 Nov
14 20:20 2:59 (remote)
dafr snark.wizard.com:ttyp15Nov
3 20:09 4:55 (remote)
dafr snark.wizard.com:ttyp1
Nov 14 06:12 19:12 (remote)
dafr snark.wizard.com:ttyp19Nov
14 06:12 19:02 (remote)
As an interesting exercise, compare this with finger information collected immediately after:
user S00 PPP ppp-122-pm1.wiza Thu Nov 14 21:29:30 - still
logged in
user S15 PPP ppp-119-pm1.wiza Thu Nov 14 22:16:35 - still
logged in
user S04 PPP ppp-121-pm1.wiza Fri Nov 15 00:03:22 - still
logged in
user S03 PPP ppp-112-pm1.wiza Thu Nov 14 22:20:23 - still
logged in
user S26 PPP ppp-124-pm1.wiza Fri Nov 15 01:26:49 - still
logged in
user S25 PPP ppp-102-pm1.wiza Thu Nov 14 23:18:00 - still
logged in
user S17 PPP ppp-115-pm1.wiza Thu Nov 14 07:45:00 - still
logged in
user S-1 0.0.0.0
Sat Aug 10 15:50:03 - still logged in
user S23 PPP ppp-103-pm1.wiza Fri Nov 15 00:13:53 - still
logged in
user S12 PPP ppp-111-pm1.wiza Wed Nov 13 16:58:12 - still
logged in
Initially, this information might not seem valuable. However, it is
often through these techniques that
you can positively identify a user. For example, certain portions of
the Internet offer varying degrees
of anonymity. Internet Relay Chat (IRC) is one such system. A person
connecting with a
UNIX-based system can effectively obscure his or her identity on IRC
but cannot easily obscure the
IP address of the machine in use. Through sustained use of both the
finger and rusers
commands, you can pin down who that user really is.
NOTE: finger and rusers are extensively discussed
in Chapter 13, "Techniques to
Hide One's Identity." Nonetheless, I'd like
to provide a brief introduction here: finger
and rusers are used to both identify and check
the current status of users logged on
to a particular machine. For example, you
can find out the user's real name (if
available), his or her last time of login,
and what command shell he or she uses. Not all
sites support these functions. In fact, most
PC-based operating systems do not without
the installation of special server software.
However, even many UNIX sites no longer
support these functions because they are so
revealing. finger and rusers are now
considered security risks in themselves.
Nevertheless, this explanation doesn't reveal the value of these utilities
in relation to cracking. In the
same way that one can finger a user, one can also finger several key
processes. Table 9.2
contains some examples.
Table 9.2. Processes that can be fingered.
Process
Purpose
lp
The Line Printer daemon
UUCP
UNIX to UNIX copy
root
Root operator
mail
The Mail System daemon
By directing finger inquiries on these accounts, you can glean valuable
information about them,
such as their base directory as well as the last time they were used
or logged in.
Thus, rusers, when coupled with finger, can produce interesting and
often revealing results. I
realize, of course, that you might trivialize this information. For,
what value is there in knowing when
and where logins take place?
In fact, there are many instances in which such information has value.
For example, if you are truly
engaged in cracking a specific system, this information can help you
build a strong database of
knowledge about your target. By watching logins, you can effectively
identify trust relationships
between machines. You can also reliably determine the habits of the
local users. All these factors
could have significant value.
Showmount
Showmount reveals some very interesting information about remote hosts.
Most importantly,
invoked with the -e command line option, showmount can provide a list
of all exported directories
on a given target. These directories might or might not be mountable
from anywhere on the Internet.
On Other Platforms
None of the mentioned UNIX utilities are scanners. However, they do
reveal important information
about the target machine. And not surprisingly, the computing community
has ported quite a few of
these utilities to other platforms (not everyone has a UNIX workstation
in their living room). It
wouldn't be fair to continue without briefly covering those ported
utilities here.
On Windows 95
Windows 95 now supports many network analysis utilities. Some of these
are straight ports from
UNIX commands, and others are programs built from the ground up. In
both cases, the majority of
these tools are shareware or freeware. You can use these tools to learn
much about networking.
NetScan Tools The NetScan Tools suite contains a series of UNIX utilities
ported to Windows 95.
Its development team claims that by utilizing ping, network administrators
can identity unauthorized
machines utilizing IP addresses on their subnets. The program also
contains ports of WHOIS, finger,
ping, and Traceroute.
Cross Reference: The Netscan Tools suite is
shareware and is available at
http://www.eskimo.com/~nwps/index.html.
Network Toolbox Network Toolbox is very similar to the Netscan Tools
suite. It consists of a port
of nine separate UNIX utilities. This utility has an interesting feature
called IP Address Search,
which allows the user to search for machines within a given range of
IP addresses. Otherwise, it has
the usual fare: finger, DNS, WHOIS, and so on. One special amenity
of this suite is that it is
exceedingly fast. This utility is discussed in greater detail later
in this chapter.
Cross Reference: You can find Network Toolbox
at
http://www.jriver.com/netbox.html.
TCP/IP Surveyor This tool is quite impressive; not only does it gather
information about networks
and reachable machines, it formats it into a graphical representation
that maps routers, workstations,
and servers.
Cross Reference: TCP/IP Surveyor is shareware
and can be found at
ftp://wuarchive.wustl.edu/systems/ibmpc/win95/netutil/wssrv32n.zip.
On Macintosh
There has been a sharp increase in development of network analysis tools
on the Macintosh
platform. Many of these applications are first rate and, in traditional
Mac platform style, are
extremely easy to use.
MacTCP Watcher This utility provides ping, DNS lookups, and general
monitoring of connections
initiated by protocols within the TCP/IP suite.
Cross Reference: As of version 1.12, this utility
has been designated freeware.
However, by the time this book is printed,
that situation might change. Get it at
http://www.share.com/share/peterlewis/mtcpw/.
Query It! Query It! is a solid utility that performs basic nslookup
inquiries. It generates information
that is very similar to that generated using the host command.
Cross Reference: Get Query It! at
http://www.cyberatl.net/~mphillip/index.html#Query
It!.
WhatRoute WhatRoute is a port of the popular UNIX utility Traceroute.
Cross Reference: WhatRoute is a freeware program
and is available at various
locations on the Internet, including http://homepages.ihug.co.nz/~bryanc/.
On AS/400
The AS/400 platform, as of AS/400 V3R1 (and Client Access/400), has
excellent internal support
for most TCP/IP utilities, including ping and netstat.
Cross Reference: For those interested in studying
the fine points of TCP/IP
implementation on AS/400, I highly recommend
the white paper "TCP/IP Connectivity
in an AS/400 Environment" by David Bernard.
(News/400. February 1996.) It can be
found at http://204.56.55.10/Education/WhitePapers/tcpip/tcpip.htm.
These utilities will always be available to users, even if scanners
are not. Moreover, because the
Internet is now traveled by more and more new users, utilities to analyze
network connections will be
commonplace on all platforms.
The Scanners
Having discussed various network analysis utilities, we can now move
on to bona fide scanners.
Let's take a look at today's most popular scanners.
NSS (Network Security Scanner)
NSS (Network Security scanner) is a very obscure scanner. If you search
for it using a popular
search engine, you will probably find fewer than 20 entries. This doesn't
mean NSS isn't in wide use.
Rather, it means that most of the FTP sites that carry it are shadowed
or simply unavailable via
archived WWW searches.
NSS differs from its counterparts in several ways, the most interesting
of which is that it's written in
Perl. (SATAN is also partially written in Perl. ISS and Strobe are
not.) This is interesting because it
means that the user does not require a C compiler. This might seem
like a small matter, but it's not.
Crackers and hackers generally start out as students. Students may
acquire shell accounts on UNIX
servers, true, but not every system administrator allows his or her
users access to a C compiler. On
the other hand, Perl is so widely used for CGI programming that most
users are allowed access to
Perl. This makes NSS a popular choice. (I should explain that most
scanners come in raw, C
source. Thus, a C compiler is required to use them.)
Also, because Perl is an interpreted (as opposed to compiled) language,
it allows the user to make
changes with a few keystrokes. It is also generally easier to read
and understand. (Why not? It's
written in plain English.) To demonstrate the importance of this, consider
the fact that many scanners
written in C allow the user only minimal control over the scan (if
the scanner comes in binary form,
that is). Without the C source code, the user is basically limited
to whatever the programmer
intended. Scanners written in Perl do not generally enforce such limitations
and are therefore more
easily extensible (and perhaps portable to any operating system running
Perl 4 or better).
NSS was reportedly written on the DEC platform (DecStation 5000 and
Ultrix 4.4). It generally
works out the box on SunOS 4.1.3 and IRIX 5.2. On other platforms,
it may require basic or
extensive porting.
The basic value of NSS is its speed. It is extremely fast. Routine checks
that it can perform include
the following:
sendmail
Anon FTP
NFS Exports
TFTP
Hosts.equiv
Xhost
NOTE: NSS will not allow you to perform Hosts.equiv
unless you have root
privileges. If this is a critical issue and
you do not currently have root, you might want to
acquire a copy of Linux, Solaris X86, or FreeBSD.
By getting one of these operating
systems and installing it at home, you can
become root. This is a common problem with
several scanners, including SATAN and certain
implementations of Internet Security
Scanner.
As you might guess, some or most of these checks (except the Hosts.equiv
query) can be conducted
by hand by any user, even without root privileges. Basically, NSS serves
the same function as most
scanners: It automates processes that might otherwise take a human
weeks to complete.
NSS comes (most often) as a tarred, g'zipped file. (In other words,
it is a zipped archive created
with gzip.exe, a popular compression tool similar to pkzip.exe.) With
the original distribution, the
author discussed the possibility of adding greater functionality, including
the following features:
AppleTalk scanning
Novell scanning
LAN manager networks
The capability to scan subnets
Briefly, the processes undertaken by NSS include
Getting the domain listing or reporting that
no such listing exists
Pinging the host to determine whether it's
alive
Scanning the ports of the target host
Reporting holes at that location
Although this is not an exhaustive treatment of NSS, there are some minor points I can offer here:
NSS does not run immediately after you unzip
and untar it. Several changes must be made to
the file. The environment variables must be
set to those applicable to your machine's
configuration. The key variables are
$TmpDir--The
temporary directory used by NSS
$YPX--The directory
where the ypx utility is located
$PING--The directory
where the executable ping is located
$XWININFO--The
directory where xwininfo is located
TIP: If your Perl include directory (where
the Perl include files are located) is
obscure and not included within your PATH
environment variable, you will have to
remedy that. Also, users should note that
NSS does require the ftplib.pl library
package.
NSS has parallel capabilities and can distribute
the scan among a number of workstations.
Moreover, it can fork processes. Those running
NSS on machines with limited resources (or
running it without permission) will want to
avoid these capabilities. These are options that can
set within the code.
Cross Reference: You can find a copy of NSS,
authored by Douglas O'Neal
(released March 28, 1995) at http://www.giga.or.at/pub/hacker/unix.
This
location was reliable as of November 20, 1996.
Strobe
Strobe (The Super Optimized TCP Port Surveyor) is a TCP port scanner
that logs all open ports on
a given machine. Strobe is fast (its author claims that an entire small
country can be scanned within a
reasonable period of time).
The key feature of Strobe is that it can quickly identify what services
are being run on a given target
(so quickly, in fact, that it takes less than 30 seconds to pin down
a server, even with a 28.8 modem
connection to the Internet). The key drawback of Strobe is that such
information is limited. At best,
a Strobe attack provides the cracker with a rough guideline, a map
of what services can be
attacked. Typical output from a Strobe scan looks like this:
localhost echo 7/tcp Echo [95,JBP]
localhost discard 9/tcp Discard [94,JBP]
localhost systat 11/tcp Active Users [89,JBP]
localhost daytime 13/tcp Daytime [93,JBP]
localhost netstat 15/tcp Netstat
localhost chargen 19/tcp Character Generator [92,JBP]
localhost ftp 21/tcp File
Transfer [Control] [96,JBP]
localhost telnet 23/tcp Telnet [112,JBP]
localhost smtp 25/tcp Simple Mail
Transfer [102,JBP]
localhost time 37/tcp Time [108,JBP]
localhost finger 79/tcp Finger [52,KLH]
localhost pop3 0/tcp Post Office
Protocol-Version 3 122
localhost sunrpc 111/tcp SUN Remote Procedure Call
[DXG]
localhost auth 113/tcp Authentication
Service [130,MCSJ]
localhost nntp 119/tcp Network News Transfer
Protocol 65,PL4
As you can see, the information is purely diagnostic in character (for
example, there are no probes
for particular holes). However, Strobe makes up for this with extensive
command-line options. For
example, in scanning hosts with large numbers of assigned ports, you
can disable all duplicate port
descriptions. (Only the first definition is printed.) Other amenities
include
Command-line option to specify starting and
ending ports
Command-line option to specify time after
which a scan will terminate if it receives no
response from a port or host
Command-line option to specify the number
of sockets to use
Command-line option to specify a file from
which Strobe will take its target hosts
Combining all these options produces a very controllable and configurable
scan. Strobe generally
comes as a tarred and g'zipped file. Contained within that distribution
is a full man page and the
binary.
Cross Reference: You can find a copy of Strobe,
authored by Julian Assange
(released 1995), at http://sunsite.kth.se/Linux/system/Network/admin/.
Pointers
In the unlikely event you acquire Strobe without also acquiring the
man page, there is a known
problem with Solaris 2.3. To prevent problems (and almost certainly
a core dump), you must disable
the use of getpeername(). This is done by adding the -g flag on the
command line.
Also, although Strobe does not perform extensive tests on remote hosts,
it leaves just as large a
footprint as early distributions of ISS. A host that is scanned with
Strobe will know it (this will most
likely appear as a run of connect requests in the /var/adm/messages
file).
SATAN (Security Administrator's Tool for Analyzing Networks)
SATAN is a computing curiosity, as are its authors. SATAN was released
(or unleashed) on the
Internet in April, 1995. Never before had a security utility caused
so much controversy.
Newspapers and magazines across the country featured articles about
it. National news broadcasts
warned of its impending release. An enormous amount of hype followed
this utility up until the
moment it was finally posted to the Net.
SATAN is, admittedly, quite a package. Written for UNIX workstations,
SATAN was--at the time
of its release--the only X Window System-based security program that
was truly user friendly. It
features an HTML interface, complete with forms to enter targets, tables
to display results, and
context-sensitive tutorials that appear when a hole has been found.
It is--in a word--extraordinary.
SATAN's authors are equally extraordinary. Dan Farmer and Weitse Venema
have both been
deeply involved in security. Readers who are unfamiliar with SATAN
might remember Dan Farmer
as the co-author of COPS, which has become a standard in the UNIX community
for checking
one's network for security holes. Venema is the author of TCP_Wrapper.
(Some people consider
TCP_Wrapper to be the grandfather of firewall technology. It replaces
inetd as a daemon, and has
strong logging options.) Both men are extremely gifted programmers,
hackers (not crackers), and
authorities on Internet security.
SATAN was designed only for UNIX. It is written primarily in C and Perl
(with some HTML
thrown in for user friendliness). It operates on a wide variety of
UNIX flavors, some with no porting
at all and others with moderate to intensive porting.
NOTE: There is a special problem with running
SATAN on Linux. The original
distribution applies certain rules that result
in flawed operation on the Linux platform.
There is also a problem with the way the select()
call is implemented in the
tcp_scan module. Lastly, if one scans an entire
subnet at one time, this will result in a
reverse fping bomb. That is, socket buffers
will overflow. Nevertheless, one site
contains not only a nicely hacked SATAN binary
for Linux, but also the diff file. (A
diff file is a file that is close but not
identical to another file. Using the diff utility, one
compares the two files. The resulting output
consists of the changes that must be
made.) These items can be found at ftp.lod.com
or one can obtain the diff file
directly from Sunsite (sunsite.unc.edu) at
/pub/Linux/system/Network/admin/satan-linux.1.1.1.diff.gz.
The package comes tarred and zipped and is available all over the world.
As the name of the
program (Security Administrator's Tool for Analyzing Networks) suggests,
it was written for the
purpose of improving network security. As such, not only must one run
it in a UNIX environment,
one must run it with root privileges.
SATAN scans remote hosts for most known holes,
including but not limited to these:
FTPD vulnerabilities and writable FTP directories
NFS vulnerabilities
NIS vulnerabilities
RSH vulnerability
sendmail
X server vulnerabilities
Once again, these are known holes. That is, SATAN doesn't do anything
that a cracker could not
ultimately do by hand. However, SATAN does perform these probes automatically
and what's
more, it provides this information in an extremely easy-to-use package.
Cross Reference: You can obtain your copy of
SATAN, written by Dan Farmer and
Weitse Venema (released April, 1995), at http://www.fish.com.
The Process: Installation
SATAN unarchives like any other utility. Each platform may differ slightly,
but in general, the
SATAN directory will extract to /satan-1.1.1. The first step (after
reading the documentation) is
to run the Perl script reconfig. This script searches for various components
(most notably, Perl)
and defines directory paths. The script reconfig will fail if it cannot
identify/define a browser.
Those folks who have installed their browser in a nonstandard directory
(and have failed to set that
variable in the PATH) will have to set that variable manually. Also,
those who do not have DNS
available (they are not running DNS on their own machine) must set
this in
/satan-1.1.1/conf/satan.cf as follows:
$dont_use_nslookup = 1;
Having resolved all the PATH issues, the user can run a make on the
distribution (make IRIX or
make SunOS). I suggest watching the compile very closely for errors.
TIP: SATAN requires a little more resources
than the average scanner, especially in
the area of RAM and processor power. If you
are experiencing sluggish performance,
there are several solutions you can try. One
of the most obvious is to get more RAM
and greater processor power. However, if that
isn't feasible, I suggest a couple things:
One is to kill as many other processes as
possible. Another is to limit your scans to 100
hosts or fewer per scan. Lastly, it is of
some significance that SATAN has a
command-line interface for those without strong
video support or with limited memory
resources.
Jakal
Jakal is a stealth scanner. That is, it will scan a domain (behind a
firewall) without leaving any trace of
the scan. According to its authors, all alpha test sites were unable
to log any activity (although it is
reported in the documentation from the authors that "Some firewalls
did allow SYN|FIN to pass
through").
Stealth scanners are a new phenomenon, their incidence rising no doubt
with the incidence of
firewalls on the Net. It's a relatively new area of expertise. So if
you test Jakal and find that a few
logs appear, don't be unforgiving.
Stealth scanners work by conducting half scans, which start (but never
complete) the entire
SYN|ACK transaction with the target host. Basically, stealth scans
bypass the firewall and evade
port scanning detectors, thus identifying what services are running
behind that firewall. (This includes
rather elaborate scan detectors such as Courtney and Gabriel. Most
of these detection systems
respond only to fully established connections.)
Cross Reference: Obtain a copy of Jakal, written
by Halflife, Jeff (Phiji) Fay, and
Abdullah Marafie at http://www.giga.or.at/pub/hacker/unix.
IdentTCPscan
IdentTCPscan is a more specialized scanner. It has the added functionality
of picking out the owner
of a given TCP port process. That is, it determines the UID of the
process. For example, running
IdentTCPscan against my own machine produced the following output:
Port: 7 Service:
(?) Userid: root
Port: 9 Service:
(?) Userid: root
Port: 11 Service:
(?) Userid: root
Port: 13 Service:
(?) Userid: root
Port: 15 Service:
(?) Userid: root
Port: 19 Service:
(?) Userid: root
Port: 21 Service:
(?) Userid: root
Port: 23 Service:
(?) Userid: root
Port: 25 Service:
(?) Userid: root
Port: 37 Service:
(?) Userid: root
Port: 79 Service:
(?) Userid: root
Port: 80 Service:
(?) Userid: root
Port: 110 Service:
(?) Userid: root
Port: 111 Service:
(?) Userid: root
Port: 113 Service:
(?) Userid: root
Port: 119 Service:
(?) Userid: root
Port: 139 Service:
(?) Userid: root
Port: 513 Service:
(?) Userid: root
Port: 514 Service:
(?) Userid: root
Port: 515 Service:
(?) Userid: root
Port: 540 Service:
(?) Userid: root
Port: 672 Service:
(?) Userid: root
Port: 2049 Service:
(?) Userid: root
Port: 6000 Service:
(?) Userid: root
This utility has a very important function. By finding the UID of the
process, misconfigurations can be
quickly identified. For example, examine this output. Seasoned security
professionals will know that
line 12 of the scan shows a serious misconfiguration. Port 80 is running
a service as root. It happens
that it is running HTTPD. This is a security problem because any attacker
who exploits weaknesses
in your CGI can run his or her processes as root as well.
I have tried many scanners. IdentTCPscan is extremely fast and as such,
it is a powerful and incisive
tool (a favorite of crackers). The utility works equally well on a
variety of platforms, including Linux,
BSDI, and SunOS. It generally comes as a compressed file containing
the source code. It is written
in C and is very compact. It also requires minimal network resources
to run. It will build without
event using most any C compiler.
Cross Reference: Obtain a copy of IdentTCPscan,
written by David Goldsmith
(released February 11, 1996), at http://www.giga.or.at/pub/hacker/unix.
CONNECT
CONNECT is a bin/sh script. Its purpose is to scan subnets for TFTP
servers. (As you might
surmise, these are difficult to find. TFTP is almost always disabled
these days.) This scanner scans
trailing IP addresses recursively. For this reason, you should send
the process into the background
(or go get yourself a beer, have some lunch, play some golf).
This scanner is of relatively little importance because TFTP is a lame
protocol. There isn't much to
gain. (Although, if the sysad at that location is negligent, you might
be able to obtain the
/etc/passwd file. Don't count on it, however. These days, the odds
of finding both an open TFTP
server and a non-shadowed passwd file on the same machine are practically
nil.)
Cross Reference: The documentation of CONNECT
is written by Joe Hentzel;
according to Hentzel, the script's author
is anonymous, and the release date is
unknown. Obtain a copy at http://www.giga.or.at/pub/hacker/unix/.
FSPScan
FSPScan scans for FSP servers. FSP stands for File Service Protocol,
an Internet protocol much
like FTP. It provides for anonymous file transfers and reportedly has
protection against network
overloading (for example, FSP never forks). Perhaps the most security-aware
feature of FSP is that
it logs the incoming user's hostname. This is considered superior to
FTP, which requests the user's
e-mail address (which, in effect, is no logging at all). FSP was popular
enough, now sporting GUI
clients for Windows and OS/2.
What's extraordinary about FSPScan is that it was written by one of
the co-authors of FSP! But
then, who better to write such a utility?
Cross Reference: Obtain a copy of FSPScan,
written by Wen-King Su (released in
1991), at http://www.giga.or.at/pub/hacker/unix.
XSCAN
XSCAN scans a subnet (or host) for X server vulnerabilities. At first
glance, this doesn't seem
particularly important. After all, most other scanners do the same.
However, XSCAN includes an
additional functionality: If it locates a vulnerable target, it immediately
starts logging the keystrokes at
that terminal.
Other amenities of XSCAN include the capability to scan multiple hosts
in the same scan. These can
be entered on the command line as arguments. (And you can specify both
hosts and subnets in a
kind of mix-and-match implementation.) The source for this utility
is included on the CD-ROM that
accompanies this book.
Cross Reference: Obtain a copy of XSCAN (release
unknown) at
http://www.giga.or.at/pub/hacker/unix.
Our Sample Scan
Our sample scan will be generated using a product called SAFEsuite.
Many of you might be familiar
with this product, which was developed by Internet Security Systems.
ISS is extremely well known
on the Net for a product called ISS. This product (the Internet Security
Scanner) was among the first
automated scanners to sell commercially.
From ISS to SAFEsuite
The first release of ISS stirred some controversy. Many people felt
that releasing such a tool free to
the Internet community would jeopardize the network's already fragile
security. (The reaction to Dan
Farmer's SATAN was very similar.) After all, why release a product
that automatically detects
weaknesses in a remote target? In the manual pages for ISS, the author
(Christopher Klaus)
addressed this issue by writing:
...To provide this to the public or at least
to the security-conscious crowd may cause people
to think that it is too dangerous for the
public, but many of the (cr/h)ackers are already aware
of these security holes and know how to exploit
them. These security holes are not deep in
some OS routines, but standard misconfigurations
that many domains on Internet tend to
show. Many of these holes are warned about
in CERT and CIAC advisories...
In early distributions of ISS, the source code for the program was included
in the package. (This
sometimes came as a shar or shell archive file and sometimes not.)
For those interested in examining
the components that make a successful and effective scanner, the full
source for the older ISS is
included on the CD-ROM that accompanies this book.
ISS has the distinction of being one of the mainstays of Internet security.
It can now be found at
thousands of sites in various forms and versions. It is a favorite
of hackers and crackers alike, being
lightweight and easy to compile on almost any UNIX-based platform.
Since the original release of
ISS, the utility has become incredibly popular. The development team
at ISS has carried this
tradition of small, portable security products onward, and SAFEsuite
is its latest effort. It is a
dramatic improvement over earlier versions.
SAFEsuite consists of several scanners:
The intranet scanner
The Web scanner
The firewall scanner
SAFEsuite is similar to SATAN in that the configuration, management,
implementation, and general
use of the program can be done in a GUI environment. This saves enormous
time and effort. It also
allows resulting information to be viewed quickly and conveniently.
However, SAFEsuite has an
additional attribute that will make it quite popular: It runs on a
Microsoft platform. SAFEsuite has
been developed for use on Microsoft Windows NT.
This is of some significance. Only recently has NT been recognized by
the UNIX community as an
acceptable server platform. This may in part be attributed to NT's
new C2 security rating. In any
event, ISS has broken through the barrier by providing a tested security
tool for a large portion of
the Microsoft-based community. I consider this a rather far-sighted
undertaking on the part of the
development team at ISS.
SAFEsuite performs a wide variety of attacks on the specified network.
These include diagnostic
routines on all of the following services:
sendmail
FTP
NNTP
Telnet
RPC
NFS
Curiously, the ISS development team also managed to add support for
analysis of a host's
vulnerability to IP spoofing and denial-of-service attacks. (This is
impressive, although one wonders
what significance there is in knowing that you're vulnerable to a DoS
attack. Few platforms are
immune to this type of attack.)
According to the folks at ISS:
SAFEsuite is the fastest, most comprehensive,
proactive UNIX network security scanner
available. It configures easily, scans quickly,
and produces comprehensive reports. SAFEsuite
probes a network environment for selected
security vulnerabilities, simulating the techniques of
a determined hacker. Depending on the reporting
options you select, SAFEsuite gives you the
following information about each vulnerability
found: location, in-depth description, and
suggested corrective actions.
In any case, those of you who have used earlier versions of ISS will
find that the SAFEsuite
distribution is slightly different. For example, earlier versions (with
the exception of one trial
distribution) were not for use in a GUI. For that reason, I will quickly
cover the scan preparation in
this tool. Perhaps the most dramatic change from the old ISS to the
new SAFEsuite is that
SAFEsuite is a commercial product.
Notes on the Server Configuration
For the purposes of demonstrating both target and attacker views of
a scan, I established a server
with the hostname SamsHack. It was configured as follows:
Machine: 486 DX-4 120 AT IBM compatible
Memory: 32 MB
Operating system: Linux 1.2.13 (Slackware)
Modem: 28.8
Network connection: PPP (pppd)
I chose Linux because it provides strong logging capabilities. Default
logging in Linux in done via a
file called /var/adm/messages. (This might differ slightly, depending
on the Linux distribution. Red
Hat Linux, for example, has a slightly different directory structure
from Slackware. In that
distribution, you will probably be focusing on the file /var/logs/messages.)
The /var/adm/messages file records status reports and messages from
the system. These naturally
include the boot routine and any problems found there, as well as dozens
of other processes the user
might initiate. (In this case, the /var/adm/messages file will log
our server's responses to the
SAFEsuite scan.)
NOTE: On some versions of Linux (and indeed,
on the majority of UNIX
distributions), more valuable logging information
can generally be found in
/var/adm/syslog than in /var/adm/messages.
This is especially so with regard to
attempts by users to gain unauthorized access
from inside the system.
System Requirements
At the time this chapter was written, the Windows NT version of SAFEsuite
was still in
development. Therefore, NT users should contact the development team
at ISS for details on how
to install on that platform. The system requirements are shown in Table
9.3.
Table 9.3. Installation requirements for SAFEsuite.
Element
Requirement
Processor Speed
Not defined
RAM
16MB or better
Networking
TCP/IP
Privileges
Root or administrator
Storage
Approximately 5MB
Browser
Any HTML-3 browser client
Miscellaneous
Solaris boxes require Motif 1.22+
SAFEsuite runs on many platforms, including but not limited to the following:
Sun OS 4.1.3 or above
Solaris 2.3 or above
HP/UX 9.05 or above
IBM AIX 3.2.5 or above
Linux 1.2.x (with kernel patch)
Linux 1.3.x prior to 1.3.75 (with patch)
Linux 1.3.76+ (no patch required)
Installing the suite is straightforward. It unpacks like any standard
UNIX utility. It should be copied
to a directory of your choice. Go to that directory and extract the
archive, using the following
command:
tar -xvf iss-xxx.tar
After you untar the archive, you will see a file labeled iss.install.
This is a Bourne shell script
that will perform the installation. (This mainly involves extracting
the distribution disks and the help
documentation, which is in HTML format.) Run this file to complete
the basic installation process by
executing the command sh iss.install. The chief executable is the xiss
file, which will launch
SAFEsuite in the X Window System, OpenWindows, or any compatible windowing
system for
UNIX.
Configuration
In this scan, I used the defaults to simplify the interpretation of
output (by output, I mean not only
the information that the scan gleans from our server, but also the
footprint, or trail, that the scanner
leaves behind). Nevertheless, the configuration options in SAFEsuite
are very incisive.
If you decide to use SAFEsuite, you might want to take advantage of
those incisive options. If so,
you need to call the Scanner Configuration window (see Figure 9.1).
Some of the options here are
similar to options formerly expressed with the command-line interface
(such as the outfile, or log file,
which contains all information recorded during the scan; this was formerly
assigned with the -o
option). Other options are entirely new, such as the option for specifying
a Web browser.
Figure 9.1.
The SAFEsuite configuration screen.
NOTE: The Web browser option isn't really an
option. To read the unabridged manual
that comes with SAFEsuite, you must specify
a browser. That is, if the user does not
specify a browser, the Help option in the
main menu window will not work. (An error
message is produced, informing you that you
have not chosen a browser.) If there is a
reason why you don't want to specify a browser
at that point--or if the machine you are
using does not have one--you can still view
the entire tutorial and manual on another
machine. Simply transport all HTML files into
a directory of your choice, start a
browser, and open index.html. The links will
work fine locally.
Special Features The options to specify additional ports is particularly
interesting. So is the
capability to add modules. SAFEsuite appears to be quite extensible.
Thus, if you hack specialized
code for probing parts of the system not covered by SAFEsuite, you
can include these modules into
the scan (as you can with Farmer and Venema's SATAN).
TIP: Even if you don't write your own security
tools, you can patch in the code of
others. For example, there are many nonestablishment
scanners out there that perform
specialized tasks. There is no reason why
these tools cannot be solidly integrated into
the SAFEsuite scan.
NOTE: The SAFEsuite program includes network
maps, which are an ingenious
creation (one that Farmer and Venema had intentions
of adding to SATAN). The
network map is a wonderful way to quickly
isolate problem machines or configurations
on your network. These maps provide a graphical
representation of your network,
visually highlighting potential danger spots.
Used in conjunction with other network
architecture tools (many which are not particularly
related to security), products like
SAFEsuite can help you to quickly design safe
network topology.
Cross Reference: For more information about
the purchase, use, or configuration of
SAFEsuite, contact ISS at its Web page (http://ISS).
The Scan
The scan took approximately two minutes. For those of you who are interested,
the network
resources consumed were relatively slim. For example, while the scan
occurred, I was also running
several other applications. The scan's activity was hardly noticeable.
The results of the scan were
enlightening. The SamsHack server was found to be vulnerable in several
areas. These vulnerabilities
ranged from trivial to serious.
NOTE: For the truly curious, I was running
SAFEsuite through a standard
configuration of MIT's X Window System. The
X Window manager was FVWM.
The rlogin Bug
One of the tests SAFEsuite runs is for a bug in the remote login program
called rlogin. Was the
SamsHack server vulnerable to rlogin attack? No.
# Rlogin Binding to Port
# Connected to Rlogin Port
# Trying to gain access via Rlogin
127.0.0.1: ---- rlogin begin output ----
127.0.0.1: ---- rlogin end output ----
# Rlogin check complete, not vulnerable.
In other areas, however, the SamsHack server was vulnerable to attack.
These vulnerabilities were
critical. Take a close look at the following log entry:
# Time Stamp(555): Rsh check: (848027962) Thu Nov 14 19:19:22
# Checking Rsh For Vulnerabilities
# Rsh Shell Binding to Port
# Sending command to Rsh
127.0.0.1: bin/bin logged in to rsh
127.0.0.1: Files grabbed from rsh into `./127.0.0.1.rsh.files'
127.0.0.1: Rsh vulnerable in hosts.equiv
# Completed Checking Rsh for Vulnerability
You'll see that line 6 suggests that some files were grabbed and saved.
Their output was sent to a file
called 127.0.0.1.rsh.files. Can you guess what file or files were saved
to that file? If you
guessed the /etc/passwd file, you are quite correct. Here are the contents
of
127.0.0.1.rsh.files:
root:bBndEhmQlYwTc:0:0:root:/root:/bin/bash
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
adm:*:3:4:adm:/var/adm:
lp:*:4:7:lp:/var/spool/lpd:
sync:*:5:0:sync:/sbin:/bin/sync
shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown
halt:*:7:0:halt:/sbin:/sbin/halt
mail:*:8:12:mail:/var/spool/mail:
news:*:9:13:news:/usr/lib/news:
uucp:*:10:14:uucp:/var/spool/uucppublic:
operator:*:11:0:operator:/root:/bin/bash
games:*:12:100:games:/usr/games:
man:*:13:15:man:/usr/man:
postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash
nobody:*:-1:100:nobody:/dev/null:
ftp:*:404:1::/home/ftp:/bin/bash
guest:*:405:100:guest:/dev/null:/dev/null
FTP also proved to be vulnerable (although the importance of this is questionable):
127.0.0.1: ---- FTP version begin output ----
SamsHack FTP server (Version wu-2.4(1) Tue Aug 8 15:50:43 CDT
1995) ready.
127.0.0.1: ---- FTP version end output ----
127.0.0.1: Please login with USER and PASS.
127.0.0.1: Guest login ok, send your complete e-mail address
as password.
127.0.0.1: Please login with USER and PASS.
127.0.0.1: ANONYMOUS FTP ALLOWED
127.0.0.1: Guest login ok, access restrictions apply.
127.0.0.1: "/" is current directory.
127.0.0.1: iss.test: Permission denied.
127.0.0.1: iss.test: Permission denied. (Delete)
127.0.0.1: Entering Passive Mode (127,0,0,1,4,217)
127.0.0.1: Opening ASCII mode data connection for /bin/ls.
127.0.0.1: Transfer complete.
127.0.0.1: Entering Passive Mode (127,0,0,1,4,219)
127.0.0.1: Opening ASCII mode data connection for /etc/passwd
(532 bytes).
127.0.0.1: Transfer complete.
127.0.0.1: Files grabbed via FTP into ./127.0.0.1.anonftp.files
127.0.0.1: Goodbye.
As you might have surmised, the passwd file for FTP was grabbed into
a file. Thus, in this chapter,
we have identified at least three serious security weaknesses in SamsHack.net:
In an earlier scan, HTTPD was being run as
root, thereby making SamsHack.net vulnerable
to WWW attacks.
SamsHack.net is vulnerable to RSH attacks.
SamsHack.net's FTP directory allows anonymous users to access the passwd file.
These weaknesses are common to many operating systems in their out-of-the-box
state. In fact, the
Linux distribution used to demonstrate this scan was out of the box.
I made no modifications to the
installation whatsoever. Therefore, you can conclude that out-of-the-box
Slackware distributions are
not secure.
I have included the entire scan log on the CD-ROM that accompanies this
book. Printing it here
would be unreasonable, as it amounts to over 15 pages of information.
You have just seen the basics of scanning a single host. But in reality,
a cracker might scan as many
as 200 hosts in a single evening. For such widespread activity, more
resources are required (greater
bandwidth, more RAM, and a more powerful processor). But resources
are not the cracker's only
concern; such a scan leaves a huge footprint. We've seen this scan
from the cracker's perspective.
Now, let's look at it from the victim's perspective.
The Other Side of the Fence
As I noted earlier, logging capabilities are extremely important. Logs
can often determine not only
when and how an attack took place, but also from where the attack originated.
On November 10, 1996, I conducted a scan identical to the one shown
previously, which was
performed on November 14, 1996. The only difference between the two
scans is that on the
November 10th scan, I employed not one but several scanners against
the SamsHack server. Those
scans and their activities were reported to the system to the file
/var/adm/messages. Take a look
at the output:
Nov 10 21:29:38 SamsHack ps[159]: connect from localhost
Nov 10 21:29:38 SamsHack netstat[160]: connect from localhost
Nov 10 21:29:38 SamsHack in.fingerd[166]: connect from localhost
Nov 10 21:29:38 SamsHack wu.ftpd[162]: connect from localhost
Nov 10 21:29:38 SamsHack in.telnetd[163]: connect from localhost
Nov 10 21:29:39 SamsHack ftpd[162]: FTP session closed
Nov 10 21:29:39 SamsHack in.pop3d[169]: connect from localhost
Nov 10 21:29:40 SamsHack in.nntpd[170]: connect from localhost
Nov 10 21:29:40 SamsHack uucico[174]: connect from localhost
Nov 10 21:29:40 SamsHack in.rlogind[171]: connect from localhost
Nov 10 21:29:40 SamsHack in.rshd[172]: connect from localhost
Nov 10 21:29:40 SamsHack telnetd[163]: ttloop: read: Broken pipe
Nov 10 21:29:41 SamsHack nntpd[170]: localhost connect
Nov 10 21:29:41 SamsHack nntpd[170]: localhost refused connection
Nov 10 21:29:51 SamsHack ps[179]: connect from localhost
Nov 10 21:29:51 SamsHack netstat[180]: connect from localhost
Nov 10 21:29:51 SamsHack wu.ftpd[182]: connect from localhost
Nov 10 21:29:51 SamsHack in.telnetd[183]: connect from localhost
Nov 10 21:29:51 SamsHack in.fingerd[186]: connect from localhost
Nov 10 21:29:51 SamsHack in.pop3d[187]: connect from localhost
Nov 10 21:29:52 SamsHack ftpd[182]: FTP session closed
Nov 10 21:29:52 SamsHack in.nntpd[189]: connect from localhost
Nov 10 21:29:52 SamsHack nntpd[189]: localhost connect
Nov 10 21:29:52 SamsHack nntpd[189]: localhost refused connection
Nov 10 21:29:52 SamsHack uucico[192]: connect from localhost
Nov 10 21:29:52 SamsHack in.rshd[194]: connect from localhost
Nov 10 21:29:52 SamsHack in.rlogind[193]: connect from localhost
Nov 10 21:29:53 SamsHack login: ROOT LOGIN ON tty2
Nov 10 21:34:17 SamsHack ps[265]: connect from pm7-6.pacificnet.net
Nov 10 21:34:17 SamsHack netstat[266]: connect from pm7-6.pacificnet.net
Nov 10 21:34:17 SamsHack wu.ftpd[268]: connect from pm7-6.pacificnet.net
Nov 10 21:34:22 SamsHack ftpd[268]: FTP session closed
Nov 10 21:34:22 SamsHack in.telnetd[269]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.fingerd[271]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack uucico[275]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.pop3d[276]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.rlogind[277]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.rshd[278]: connect from pm7-6.pacificnet.net
Nov 10 21:34:23 SamsHack in.nntpd[279]: connect from pm7-6.pacificnet.net
Nov 10 21:34:28 SamsHack telnetd[269]: ttloop: read: Broken pipe
Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net connect
Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net refused connection
Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199
on illegal port
The first thing I want you to notice is the time. The first line of
this log excerpt reports the time as
21:29:38. The last line of the scan reports 21:34:33. Thus, the entire
range of activity occurred within
a five-minute period. Next, I want you to take a good look at what's
happening here. You will see
that nearly every open, available port has been attacked (some of them
more than once). And, on at
least one occasion, the IP address from which the attack originated
appears clearly within the log
(specifically, on the last line of the small snippet of log I have
provided). The line appears as
Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port
It is quite obvious that any system administrator looking for attacks
like this one needn't look far.
Keep in mind that in this example, I was not running any special logging
utilities or wrappers. Just
plain, old logging, which is on by default in a factory install.
So the average system administrator needn't do more than search the
/var/adm/message file (or
its equivalent) for runs of connection requests. However, you will
be surprised to know that an
overwhelming number of system administrators do not do this on a regular
basis.
Other Platforms
Scanners have traditionally been designed for UNIX. But what about other
operating systems?
There are two aspects to consider about scanners with regard to operating
system. The first is what
operating system the target machine runs. The second is what operating
system the attacking
machine runs. I want to discuss these in relation to platforms other
than UNIX.
The Target Machine As Another Platform
Scanning platforms other than UNIX might or might not be of significant
value. At least, this is true
with respect to deployment of TCP port scanners. This is because the
majority of non-UNIX
platforms that support TCP/IP support only portions of TCP/IP. In fact,
some of those TCP/IP
implementations are quite stripped down. Frankly, several TCP/IP implementations
have support for
a Web server only. (Equally, even those that have support for more
might not evidence additional
ports or services because these have been disabled.)
This is the main reason that certain platforms, like the Macintosh platform,
have thus far seen fewer
intrusions than UNIX-based operating systems. The fewer services you
actually run, the less likely it
is that a hole will be found. That is common sense.
Equally, many platforms other than UNIX do support extensive TCP/IP.
AS/400 is one such
platform. Microsoft Windows NT (with Internet Information Server) is
another. Certainly, any
system that runs any form of TCP/IP could potentially support a wide
range of protocols. Novell
NetWare, for example, has long had support for TCP/IP.
It boils down to this: The information you will reap from scanning a
wide variety of operating systems
depends largely on the construct of the /etc/services file or the targeted
operating system's
equivalent. This file defines what ports and services are available.
This subject will discussed later, as
it is relevant to (and implemented differently on) varied operating
systems. In Chapter 18, "Novell,"
for example, I examine this file and its uses on the Novell NetWare
platform.
The Scanning Machine on Another Platform
Using a platform other than UNIX to perform a scan is another matter.
Port scanning utilities for
other platforms are available and, as you might surmise, we're going
to use one momentarily. The
product I will be using to demonstrate this process runs in Windows
95. It is called Network
Toolbox.
Network Toolbox
Network Toolbox is a TCP/IP utility for Windows 95. (This program was
discussed earlier in this
chapter in the section on network analysis utilities.) It was developed
by J. River Co. of Minneapolis,
Minnesota (it can be reached at info@jriver.com). The utility includes
a port scanner. I will not
conduct an exhaustive analysis of other utilities available within
the application (though there are
many, including ping). Instead, I would like to give you a quick start.
Figure 9.2 shows opening
screen of the application.
1. Before conducting a scan with Network Toolbox,
you must first set the scan properties. By
default, the Network Toolbox port scan only
queries 14 TCP/IP ports. This is insufficient for
a complete scan. The output of a default scan
would look like this:
port: 9 discard
Service available
port: 13 daytime
Service available
port: 21
ftp Service available
port: 23 telnet
Service available
port: 25
smtp Service available
port: 37
time Service available
port: 79 finger
Service available
port: 80
http Service available
port:110
pop3 Service available
port:111 portmap
Service available
port:512
exec Service available
port:513
login Service available
port:514
shell Service available
port:540
uucp Service available
2. To obtain a more comprehensive scan, you
must first set the scan's properties. To do so,
click the Options button to call the Options
panel (see Figure 9.3).
Figure 9.2.
The Network Toolbox opening screen.
Figure 9.3.
The Network Toolbox Options panel.
3. After you open the Network Toolbox Options
panel, select the tab marked Port Scanner.
This will bring you to options and settings
for the scan (see Figure 9.4).
Figure 9.4.
The Network Toolbox Port Scanner Option tab.
4. The Port Scanner Option tab provides a series
of options regarding ports. One is to specify
a range of ports by number. This is very useful,
though I would probably scan all available
ports.
5. The last step is to actually scan the targeted
host. This is done by choosing the Scan button
shown in Figure 9.5.
Figure 9.5.
Select the Scan button to scan the targeted host.
The port scanner in Network Toolbox is fast and accurate. The average
scan takes less than a
minute. I would characterize this as a good product. Moreover, it provides
ports of several other
UNIX utilities of interest.
The information gleaned using this utility is quite similar to that
obtained using Strobe. It will not tell
you the owner of a process, nor does the Network Toolbox port scanner
try doors or windows. (In
other words, it makes no attempt to penetrate the target network.)
However, it is valuable because it
can quickly determine what processes are now running on the target.
Summary
In this chapter, you have learned a little bit about scanners, why they
were developed, and how they
work. But education about scanners doesn't stop there. You might be
surprised to know that new
scanners crop up every few months or so, and these are usually more
functional than their
predecessors.
Internet security is a constantly changing field. As new holes are discovered,
they are posted to
various mailing lists, alert rosters, and newsgroups. Most commonly,
such alerts end up at CERT or
CIAC. Crackers and hackers alike belong to such mailing lists and often
read CERT advisories.
Thus, these new holes become common knowledge often minutes or hours
after they are posted.
As each new hole is uncovered, capabilities to check for the new hole
are added to existing
scanners. The process is not particularly complex. In most cases, the
cracker need only write a small
amount of additional code, which is then pasted into the existing source
code of his or her scanner.
The scanner is then recompiled and voilà! The cracker is ready
to exploit a new hole on a wide
scale. This is a never-ending process.
System administrators must learn about and implement scanners. It is
a fact of life. Those who fail to
do so will suffer the consequences, which can be very grave. I believe
scanners can educate new
system administrators as to potential security risks. If for no other
reason than this, scanners are an
important element of Internet security. I recommend trying out as many
as possible.
E-Mail any questions, comments or deaththreats to:
ameister@vol.com
Copyright © AcidMeister...
Visit him at:
http://www.vol.com/~ameister
Disclaimer:
This is for Educational purposes only it should not be used as a guide to
cause havoc or to hack. He He He, good luck!!! And don't get caught. I
would hate to see you in a cell with your 300 pound Bruno The Gay Ax
murderer. He He He